Menguasai JavaScript Module Federation: Kekuatan Shared Scope dan Berbagi Dependensi

Dalam lanskap pengembangan web yang berkembang pesat, membangun aplikasi yang terukur dan mudah dipelihara seringkali melibatkan penerapan pola arsitektur yang canggih. Di antara ini, konsep microfrontend telah mendapatkan daya tarik yang signifikan, memungkinkan tim untuk mengembangkan dan menyebarkan bagian dari aplikasi secara independen. Inti dari memungkinkan integrasi tanpa batas dan berbagi kode yang efisien antara unit independen ini terletak pada plugin Module Federation Webpack, dan komponen penting dari kekuatannya adalah shared scope.

Panduan komprehensif ini menggali lebih dalam mekanisme shared scope dalam JavaScript Module Federation. Kita akan menjelajahi apa itu, mengapa penting untuk berbagi dependensi, bagaimana cara kerjanya, dan strategi praktis untuk mengimplementasikannya secara efektif. Tujuan kami adalah untuk membekali pengembang dengan pengetahuan untuk memanfaatkan fitur canggih ini untuk meningkatkan kinerja, mengurangi ukuran bundel, dan meningkatkan pengalaman pengembang di berbagai tim pengembangan global.

Apa itu JavaScript Module Federation?

Sebelum menyelami shared scope, penting untuk memahami konsep dasar Module Federation. Diperkenalkan dengan Webpack 5, Module Federation adalah solusi build-time dan run-time yang memungkinkan aplikasi JavaScript untuk berbagi kode secara dinamis (seperti library, framework, atau bahkan seluruh komponen) antara aplikasi yang dikompilasi secara terpisah. Ini berarti Anda dapat memiliki beberapa aplikasi berbeda (sering disebut sebagai 'remote' atau 'konsumen') yang dapat memuat kode dari aplikasi 'container' atau 'host', dan sebaliknya.

Manfaat utama Module Federation meliputi:

• Berbagi Kode: Hilangkan kode yang berlebihan di beberapa aplikasi, kurangi ukuran bundel keseluruhan, dan tingkatkan waktu pemuatan.
• Penyebaran Independen: Tim dapat mengembangkan dan menyebarkan bagian yang berbeda dari aplikasi besar secara independen, mendorong kelincahan dan siklus rilis yang lebih cepat.
• Agnostik Teknologi: Meskipun terutama digunakan dengan Webpack, ini memfasilitasi berbagi di berbagai alat build atau framework sampai batas tertentu, mempromosikan fleksibilitas.
• Integrasi Runtime: Aplikasi dapat disusun pada runtime, memungkinkan pembaruan dinamis dan struktur aplikasi yang fleksibel.

Masalah: Dependensi Redundan di Microfrontend

Pertimbangkan skenario di mana Anda memiliki beberapa microfrontend yang semuanya bergantung pada versi yang sama dari library UI populer seperti React, atau library manajemen state seperti Redux. Tanpa mekanisme untuk berbagi, setiap microfrontend akan membundel salinan dependensinya sendiri. Ini mengarah ke:

• Ukuran Bundel yang Membengkak: Setiap aplikasi menduplikasi library umum secara tidak perlu, yang menyebabkan ukuran unduhan yang lebih besar bagi pengguna.
• Peningkatan Konsumsi Memori: Beberapa instance library yang sama yang dimuat di browser dapat menghabiskan lebih banyak memori.
• Perilaku Tidak Konsisten: Versi library bersama yang berbeda di seluruh aplikasi dapat menyebabkan bug halus dan masalah kompatibilitas.
• Pemborosan Sumber Daya Jaringan: Pengguna mungkin mengunduh library yang sama beberapa kali jika mereka bernavigasi di antara microfrontend yang berbeda.

Di sinilah shared scope Module Federation berperan, menawarkan solusi elegan untuk tantangan ini.

Memahami Shared Scope Module Federation

Shared scope, sering dikonfigurasi melalui opsi shared dalam plugin Module Federation, adalah mekanisme yang memungkinkan beberapa aplikasi yang disebarkan secara independen untuk berbagi dependensi. Ketika dikonfigurasi, Module Federation memastikan bahwa satu instance dari dependensi yang ditentukan dimuat dan tersedia untuk semua aplikasi yang membutuhkannya.

Intinya, shared scope bekerja dengan membuat registri atau container global untuk modul bersama. Ketika sebuah aplikasi meminta dependensi bersama, Module Federation memeriksa registri ini. Jika dependensi sudah ada (yaitu, dimuat oleh aplikasi lain atau host), ia menggunakan instance yang ada tersebut. Jika tidak, ia memuat dependensi dan mendaftarkannya dalam shared scope untuk penggunaan di masa mendatang.

Konfigurasinya biasanya terlihat seperti ini:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... konfigurasi webpack lainnya
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Opsi Konfigurasi Utama untuk Dependensi Bersama:

• singleton: true: Ini mungkin opsi yang paling penting. Ketika disetel ke true, ini memastikan bahwa hanya satu instance dari dependensi bersama yang dimuat di semua aplikasi yang mengonsumsi. Jika beberapa aplikasi mencoba memuat dependensi singleton yang sama, Module Federation akan memberi mereka instance yang sama.
• eager: true: Secara default, dependensi bersama dimuat secara lazy, yang berarti mereka hanya diambil ketika secara eksplisit diimpor atau digunakan. Menyetel eager: true memaksa dependensi untuk dimuat segera setelah aplikasi dimulai, bahkan jika tidak segera digunakan. Ini dapat bermanfaat untuk library penting seperti framework untuk memastikan bahwa mereka tersedia sejak awal.
• requiredVersion: '...': Opsi ini menentukan versi yang diperlukan dari dependensi bersama. Module Federation akan mencoba untuk mencocokkan versi yang diminta. Jika beberapa aplikasi membutuhkan versi yang berbeda, Module Federation memiliki mekanisme untuk menangani ini (dibahas nanti).
• version: '...': Anda dapat secara eksplisit menyetel versi dependensi yang akan dipublikasikan ke shared scope.
• import: false: Pengaturan ini memberi tahu Module Federation untuk tidak secara otomatis membundel dependensi bersama. Sebagai gantinya, ia mengharapkan itu disediakan secara eksternal (yang merupakan perilaku default saat berbagi).
• packageDir: '...': Menentukan direktori paket untuk menyelesaikan dependensi bersama dari, berguna dalam monorepo.

Bagaimana Shared Scope Memungkinkan Berbagi Dependensi

Mari kita uraikan prosesnya dengan contoh praktis. Bayangkan kita memiliki aplikasi 'container' utama dan dua aplikasi 'remote', `app1` dan `app2`. Ketiga aplikasi bergantung pada `react` dan `react-dom` versi 18.

Skenario 1: Aplikasi Kontainer Berbagi Dependensi

Dalam pengaturan umum ini, aplikasi kontainer mendefinisikan dependensi bersama. File `remoteEntry.js`, yang dihasilkan oleh Module Federation, mengekspos modul bersama ini.

Konfigurasi Webpack Kontainer (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Sekarang, `app1` dan `app2` akan mengonsumsi dependensi bersama ini.

Konfigurasi Webpack `app1` (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Konfigurasi Webpack `app2` (`app2/webpack.config.js`):

Konfigurasi untuk `app2` akan mirip dengan `app1`, juga mendeklarasikan `react` dan `react-dom` sebagai shared dengan persyaratan versi yang sama.

Cara kerjanya saat runtime:

1. Aplikasi kontainer dimuat terlebih dahulu, membuat instance `react` dan `react-dom` yang dibagikan tersedia di shared scope Module Federation-nya.
2. Ketika `app1` dimuat, ia meminta `react` dan `react-dom`. Module Federation di `app1` melihat bahwa ini ditandai sebagai shared dan `singleton: true`. Ia memeriksa global scope untuk instance yang ada. Jika kontainer sudah memuatnya, `app1` menggunakan kembali instance tersebut.
3. Demikian pula, ketika `app2` dimuat, ia juga menggunakan kembali instance `react` dan `react-dom` yang sama.

Ini menghasilkan hanya satu salinan `react` dan `react-dom` yang dimuat ke dalam browser, secara signifikan mengurangi total ukuran unduhan.

Skenario 2: Berbagi Dependensi Antara Aplikasi Remote

Module Federation juga memungkinkan aplikasi remote untuk berbagi dependensi di antara mereka sendiri. Jika `app1` dan `app2` keduanya menggunakan library yang *tidak* dibagikan oleh kontainer, mereka masih dapat membagikannya jika keduanya mendeklarasikannya sebagai shared dalam konfigurasi masing-masing.

Contoh: Katakanlah `app1` dan `app2` keduanya menggunakan library utilitas `lodash`.

Konfigurasi Webpack `app1` (menambahkan lodash):

            
// ... dalam ModuleFederationPlugin untuk app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

Konfigurasi Webpack `app2` (menambahkan lodash):

            
// ... dalam ModuleFederationPlugin untuk app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

Dalam hal ini, bahkan jika kontainer tidak secara eksplisit berbagi `lodash`, `app1` dan `app2` akan berhasil berbagi satu instance `lodash` di antara mereka sendiri, asalkan mereka dimuat dalam konteks browser yang sama.

Menangani Ketidakcocokan Versi

Salah satu tantangan paling umum dalam berbagi dependensi adalah kompatibilitas versi. Apa yang terjadi ketika `app1` membutuhkan `react` v18.1.0 dan `app2` membutuhkan `react` v18.2.0? Module Federation menyediakan strategi yang kuat untuk mengelola skenario ini.

1. Pencocokan Versi yang Ketat (Perilaku default untuk `requiredVersion`)

Ketika Anda menentukan versi yang tepat (misalnya, '18.1.0') atau rentang yang ketat (misalnya, '^18.1.0'), Module Federation akan memberlakukan ini. Jika sebuah aplikasi mencoba memuat dependensi bersama dengan versi yang tidak memenuhi persyaratan aplikasi lain yang sudah menggunakannya, itu dapat menyebabkan kesalahan.

2. Rentang Versi dan Fallback

Opsi requiredVersion mendukung rentang semantic versioning (SemVer). Misalnya, '^18.0.0' berarti versi apa pun dari 18.0.0 hingga (tetapi tidak termasuk) 19.0.0. Jika beberapa aplikasi membutuhkan versi dalam rentang ini, Module Federation biasanya akan menggunakan versi kompatibel tertinggi yang memenuhi semua persyaratan.

Pertimbangkan ini:

• Kontainer: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

Jika kontainer dimuat terlebih dahulu, ia menetapkan `react` v18.0.0 (atau versi apa pun yang sebenarnya dibundel). Ketika `app1` meminta `react` dengan `^18.1.0`, itu mungkin gagal jika versi kontainer kurang dari 18.1.0. Namun, jika `app1` dimuat terlebih dahulu dan menyediakan `react` v18.1.0, dan kemudian `app2` meminta `react` dengan `^18.2.0`, Module Federation akan mencoba memenuhi persyaratan `app2`. Jika instance `react` v18.1.0 sudah dimuat, itu mungkin memunculkan kesalahan karena v18.1.0 tidak memenuhi `^18.2.0`.

Untuk mengurangi ini, praktik terbaik adalah mendefinisikan dependensi bersama dengan rentang versi terluas yang dapat diterima, biasanya di aplikasi kontainer. Misalnya, menggunakan '^18.0.0' memungkinkan fleksibilitas. Jika aplikasi remote tertentu memiliki dependensi keras pada versi patch yang lebih baru, itu harus dikonfigurasi untuk secara eksplisit menyediakan versi itu.

3. Menggunakan `shareKey` dan `shareScope`

Module Federation juga memungkinkan Anda untuk mengontrol kunci di mana modul dibagikan dan shared scope tempat ia berada. Ini dapat berguna untuk skenario lanjutan, seperti berbagi versi yang berbeda dari library yang sama di bawah kunci yang berbeda.

4. Opsi `strictVersion`

Ketika strictVersion diaktifkan (yang merupakan default untuk requiredVersion), Module Federation memunculkan kesalahan jika dependensi tidak dapat dipenuhi. Menyetel strictVersion: false dapat memungkinkan penanganan versi yang lebih lunak, di mana Module Federation mungkin mencoba menggunakan versi yang lebih lama jika versi yang lebih baru tidak tersedia, tetapi ini dapat menyebabkan kesalahan runtime.

Praktik Terbaik untuk Menggunakan Shared Scope

Untuk memanfaatkan shared scope Module Federation secara efektif dan menghindari kesalahan umum, pertimbangkan praktik terbaik ini:

1. Pusatkan Dependensi Bersama: Tunjuk aplikasi utama (seringkali kontainer atau aplikasi library bersama khusus) untuk menjadi sumber kebenaran untuk dependensi umum dan stabil seperti framework (React, Vue, Angular), library komponen UI, dan library manajemen state.
2. Definisikan Rentang Versi yang Luas: Gunakan rentang SemVer (misalnya, '^18.0.0') untuk dependensi bersama di aplikasi berbagi utama. Ini memungkinkan aplikasi lain untuk menggunakan versi yang kompatibel tanpa memaksa pembaruan ketat di seluruh ekosistem.
3. Dokumentasikan Dependensi Bersama dengan Jelas: Pertahankan dokumentasi yang jelas tentang dependensi mana yang dibagikan, versinya, dan aplikasi mana yang bertanggung jawab untuk membagikannya. Ini membantu tim memahami grafik dependensi.
4. Pantau Ukuran Bundel: Secara teratur analisis ukuran bundel aplikasi Anda. Shared scope Module Federation harus mengarah pada pengurangan ukuran chunk yang dimuat secara dinamis karena dependensi umum dieksternalisasi.
5. Kelola Dependensi Non-Deterministik: Berhati-hatilah dengan dependensi yang sering diperbarui atau memiliki API yang tidak stabil. Berbagi dependensi semacam itu mungkin memerlukan manajemen dan pengujian versi yang lebih hati-hati.
6. Gunakan `eager: true` dengan Bijak: Sementara `eager: true` memastikan dependensi dimuat lebih awal, penggunaan berlebihan dapat menyebabkan pemuatan awal yang lebih besar. Gunakan untuk library penting yang penting untuk startup aplikasi.
7. Pengujian Sangat Penting: Uji secara menyeluruh integrasi microfrontend Anda. Pastikan bahwa dependensi bersama dimuat dengan benar dan bahwa konflik versi ditangani dengan baik. Pengujian otomatis, termasuk pengujian integrasi dan end-to-end, sangat penting.
8. Pertimbangkan Monorepo untuk Kesederhanaan: Untuk tim yang memulai dengan Module Federation, mengelola dependensi bersama dalam monorepo (menggunakan alat seperti Lerna atau Yarn Workspaces) dapat menyederhanakan pengaturan dan memastikan konsistensi. Opsi `packageDir` sangat berguna di sini.
9. Tangani Kasus Ujung dengan `shareKey` dan `shareScope`: Jika Anda menemukan skenario versi yang kompleks atau perlu mengekspos versi yang berbeda dari library yang sama, jelajahi opsi `shareKey` dan `shareScope` untuk kontrol yang lebih terperinci.
10. Pertimbangan Keamanan: Pastikan bahwa dependensi bersama diambil dari sumber yang tepercaya. Terapkan praktik terbaik keamanan untuk alur build dan proses penyebaran Anda.

Dampak dan Pertimbangan Global

Untuk tim pengembangan global, Module Federation dan shared scope-nya menawarkan keuntungan yang signifikan:

• Konsistensi Lintas Wilayah: Memastikan bahwa semua pengguna, terlepas dari lokasi geografis mereka, mengalami aplikasi dengan dependensi inti yang sama, mengurangi inkonsistensi regional.
• Siklus Iterasi Lebih Cepat: Tim di zona waktu yang berbeda dapat mengerjakan fitur atau microfrontend independen tanpa terus-menerus khawatir tentang menduplikasi library umum atau menginjak kaki satu sama lain mengenai versi dependensi.
• Dioptimalkan untuk Jaringan yang Beragam: Mengurangi ukuran unduhan keseluruhan melalui dependensi bersama sangat bermanfaat bagi pengguna dengan koneksi internet yang lebih lambat atau terukur, yang lazim di banyak bagian dunia.
• Penyederhanaan Onboarding: Pengembang baru yang bergabung dengan proyek besar dapat lebih mudah memahami arsitektur aplikasi dan manajemen dependensi ketika library umum didefinisikan dan dibagikan dengan jelas.

Namun, tim global juga harus memperhatikan:

• Strategi CDN: Jika dependensi bersama dihosting di CDN, pastikan CDN memiliki jangkauan global yang baik dan latensi rendah untuk semua wilayah target.
• Dukungan Offline: Untuk aplikasi yang membutuhkan kemampuan offline, mengelola dependensi bersama dan caching mereka menjadi lebih kompleks.
• Kepatuhan Regulasi: Pastikan bahwa berbagi library mematuhi setiap peraturan perizinan perangkat lunak atau privasi data yang relevan di yurisdiksi yang berbeda.

Kesalahan Umum dan Cara Menghindarinya

1. `singleton` Dikonfigurasi Secara Salah

Masalah: Lupa menyetel singleton: true untuk library yang seharusnya hanya memiliki satu instance.

Solusi: Selalu setel singleton: true untuk framework, library, dan utilitas yang ingin Anda bagikan secara unik di seluruh aplikasi Anda.

2. Persyaratan Versi yang Tidak Konsisten

Masalah: Aplikasi yang berbeda menentukan rentang versi yang sangat berbeda dan tidak kompatibel untuk dependensi bersama yang sama.

Solusi: Standarkan persyaratan versi, terutama di aplikasi kontainer. Gunakan rentang SemVer yang luas dan dokumentasikan pengecualian apa pun.

3. Berbagi Berlebihan Library yang Tidak Penting

Masalah: Mencoba berbagi setiap library utilitas kecil, yang mengarah ke konfigurasi yang kompleks dan potensi konflik.

Solusi: Fokus pada berbagi dependensi besar, umum, dan stabil. Utilitas kecil yang jarang digunakan mungkin lebih baik dibundel secara lokal untuk menghindari kompleksitas.

4. Tidak Menangani File `remoteEntry.js` dengan Benar

Masalah: File `remoteEntry.js` tidak dapat diakses atau dilayani dengan benar ke aplikasi yang mengonsumsi.

Solusi: Pastikan strategi hosting Anda untuk remote entry kuat dan bahwa URL yang ditentukan dalam konfigurasi `remotes` akurat dan dapat diakses.

5. Mengabaikan Implikasi `eager: true`

Masalah: Menyetel eager: true pada terlalu banyak dependensi, yang mengarah ke waktu pemuatan awal yang lambat.

Solusi: Gunakan eager: true hanya untuk dependensi yang benar-benar penting untuk rendering awal atau fungsionalitas inti aplikasi Anda.

Kesimpulan

Shared scope JavaScript Module Federation adalah alat yang ampuh untuk membangun aplikasi web modern yang terukur, terutama dalam arsitektur microfrontend. Dengan memungkinkan berbagi dependensi yang efisien, ia mengatasi masalah duplikasi kode, pembengkakan, dan inkonsistensi, yang mengarah pada peningkatan kinerja dan pemeliharaan. Memahami dan mengonfigurasi opsi shared dengan benar, terutama properti singleton dan requiredVersion, adalah kunci untuk membuka manfaat ini.

Karena tim pengembangan global semakin mengadopsi strategi microfrontend, menguasai shared scope Module Federation menjadi sangat penting. Dengan mematuhi praktik terbaik, mengelola versi dengan hati-hati, dan melakukan pengujian menyeluruh, Anda dapat memanfaatkan teknologi ini untuk membangun aplikasi yang kuat, berkinerja tinggi, dan mudah dipelihara yang melayani basis pengguna internasional yang beragam secara efektif.

Rangkullah kekuatan shared scope, dan buka jalan bagi pengembangan web yang lebih efisien dan kolaboratif di seluruh organisasi Anda.